[Workflows] add subscribe documentation and changelog - #33361

Fix the following review findings in PR #33361 (https://github.com/cloudflare/cloudflare-docs/pull/33361).

Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
  or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.

The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.

---

## Code Review

### Warnings (1)

#### CR-637d8152e80a · Incorrect API description
- **File:** `src/content/docs/workflows/build/workers-api.mdx` line 775
- **Issue:** The text claims each `next()` call "returns the next matching `WorkflowInstanceEvent`". The sibling page added in this PR (`subscribe-to-instance-events.mdx`) shows `next()` returns an async-iterator result: `const result = await subscription.next(); if (result.done) break; console.log(result.value.type, ...)`. Following this wording, a user would treat the result directly as the event (e.g. `event.type`) instead of `result.value.type`, producing undefined fields.
- **Fix:** Reword to say each `next()` call returns the next iterator result (`{ done, value }`) whose `value` is the matching `WorkflowInstanceEvent`, matching the examples in the linked Subscribe to events page.

### Suggestions (2)

#### CR-42dda900342f · Incorrect API argument in example
- **File:** `src/content/docs/workflows/build/subscribe-to-instance-events.mdx` line 59
- **Issue:** The first example creates an instance with `create({ params: { reportId: "report-123" } })` and no `id`, so the instance ID is auto-generated. The filter example then retrieves the instance with `env.MY_WORKFLOW.get("report-123")`, reusing the params value as the instance ID — `get()` throws if the ID does not exist (per the workers-api docs), so the example fails if a reader follows the two snippets together.
- **Fix:** Either pass `id: "report-123"` in the `create()` call in the first example, or use a distinct placeholder (e.g. `get("abc-123")`) in the filter example so the ID is not confused with the `reportId` param.

#### CR-7035726f39ce · Inaccurate API return shape
- **File:** `src/content/docs/workflows/build/workers-api.mdx` line 775
- **Issue:** The text states each `next()` call "returns the next matching `WorkflowInstanceEvent`", but the companion page added in this PR (`subscribe-to-instance-events.mdx`) shows `next()` resolving to an iterator result object (`const result = await subscription.next(); if (result.done) ...; result.value.type`), with the event at `result.value`. A reader following this description would expect `next()` to resolve directly to the event.
- **Fix:** Clarify that `next()` resolves to a `{ done, value }` result and the event is available at `result.value`, matching the usage shown on the Subscribe to events page.